做好运维知识自动化系统不容易

12月7号要参加电力信创专委会的一个会，6号晚上同事都在加班赶OB专版，我负责帮忙测试，就一边测试一边写点东西。今天要发的内容有点散因为这是昨晚和在测试间歇和今早在地铁里写的，内容不是很连贯。

从目前的 情况看，OB专版至少还得测试一周才能封板。分布式数据库太复杂，而且OB 4和OB3之间差别太大，测试也不大容易做好。因为实验室的服务器资源有限，以前OB3集群都部署在一个很小的环境中，稍微一加压，内存就爆掉了，因此针对OB3.X版本的工具测试并不到位。前几天把一套3节点的OB4.2.1铲掉，重新搭了一个OB3.2.4的环境,以便于让各种脚步针对这个版本做全面测试。测试做得多一点，问题就层出不穷地冒出来了。我们做这么一个运维工具都如此复杂，就不要说复杂到了极点的数据库产品了。

昨天还发生了一个值得记录下来的小插曲，在一个用户那里DSMART的表空间可用时长指标出了问题，在半夜产生了误报警。用户是一套19.20的RAC，采集回来的容量数据中居然有一个表空间容量是0，因此触发了错误的报警。表空间容量为零从数据库原理上理解我觉得可能遇到了BUG，正常情况下不大可能发生。公司的同事认为应该在这里打印一个日志，从而确定采集回来的数据是没错的，这个指标错误确实是ORACLE BUG导致的。我却不这么认为，我觉得加一个打印日志是可以的，便于跟踪这个错误，但是更重要的是我们的软件中要对采集回来明显有问题而且必然产生报警的指标在采集程序中做一次复核。我们要做的是为客户提供遇到数据库BUG还能良好工作的运维辅助软件，而不是向客户解释一个错误的报警的责任并不在我们身上。

今天为了给OB3加点压，我把MySQL租户和Oracle租户的benchmark环境都搭好了。按照OB官网上创建Oracle租户的表的时候，发现OB官网给出的脚本居然存在问题，估计OB的同学并没有对这个脚本做过测试。幸好遇到的都是小问题，调试了几次后，我找到了解决问题的办法。

在压力机上同时给ORACLE租户和MYSQL租户加压的效果还是不错的，OB 3的租户隔离做得已经很不错了。不过压测时也遇到了一些小问题，Oracle租户是比较稳定的，TPMC一直稳定在5万左右（我的环境是3节点，每个节点4C/10G），而MySQL租户（也是三节点，4C/6G，内存配得少一点）似乎不是很稳定，刚开始的时候也能达到4万多，不过慢慢会下降到8000左右。为什么会产生这种情况，这两天我会和OB的同学一起来分析，也许从中可以发现一些OB优化的新知识。

压力环境下，数据库的告警不算多，主要的健康状态还是可以接受的。被压测的Oracle和MySQL租户的健康度还算不错。

11月的OB年度发布会上我们的收获很大，因为我们遇到了很多真实的OB用户，通过和他们的交流，我们了解了OB用户的很多真实需求，这一天时间我们收获的运维知识比我们闭门造车半年还要多。我们根据现场遇到的一些用户的需求进一步完善了工具包，把一些比较常用的功能都放到了工具包里。现在这个工具包比起11月我们宣布发布专版的时候看上去靠谱多了。我也十分理解了为啥数据库厂商发布的新版本往往都不大靠谱，很多用户在关键系统上至少要等半年一年，出了一两个升级版才敢去使用。O记好像也是这个路数。

在数据库工具里，也准备预制一些常用查询语句。OB数据库不同版本（目前我们支持3.x/4.x）和不同租户之间数据字典表存在一定的差异。

因此我们在配置文件里也做了版本和租户的区别。当然这些都是出厂的设置，用户可以自行添加。不过我们也希望在出厂时把这些内容也丰富一下。常用查询也算是运维知识的一部分吧。

在OB专版正式发布之前，我们也希望更多的和OB用户交流，听听他们都需要些什么功能。因此我也希望有OB用户看到这篇文章与我交流交流。来自用户的真实需求是我们现在最需要的食粮。也希望在今天的信创专委会上能够遇到一些OB的用户，认真听听他们的声音。